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Abstract 


The Internet Key Exchange Version 2 (IKEv2) protocol did have support 
for raw public keys, but it only supported RSA raw public keys. In 
constrained environments, it is useful to make use of other types of 
public keys, such as those based on Elliptic Curve Cryptography. 

This document updates RFC 7296, adding support for other types of raw 
public keys to IKEv2. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7670. 
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1. Introduction 


This document replaces an algorithm-specific version of raw public 
keys of the Internet Key Exchange Version 2 (IKEv2) [RFC7296] with a 
generic version of raw public keys that is algorithm agnostic. 


In [RFC5996], IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a 
DER-encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other 
raw public-key types are, however, not supported. In [RFC7296], this 
feature was removed; this document reintroduces support for raw 
public keys to IKEv2 in a more generic way. 


DNSSEC allows public keys to be associated with domain names for 
usage with security protocols like IKEv2 and Transport Layer Security 
(TLS) [RFC5246] but it relies on extensions in those protocols to be 
specified. 


The Raw Public Keys in Transport Layer Security specification 
([RFC7250]) adds generic support for raw public keys to TLS by 
reusing the SubjectPublicKeyInfo format from the X.509 Public-Key 
Infrastructure Certificate profile [RFC5280]. 


This document is similar to the Raw Public Keys in Transport Layer 
Security specification and applies the concept to IKEv2 to support 
all public-key formats defined by PKIX. This approach also allows 
future public-key extensions to be supported without the need to 
introduce further enhancements to IKEv2. 
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To support new types of public keys in IKEv2, the following changes 
are needed: 


o A new Certificate Encoding format needs to be defined for carrying 
the SubjectPublicKeyInfo structure. Section 3 specifies this new 
encoding format. 


o A new Certificate Encoding that has been allocated by IANA. 
Section 5 contains the details about the IANA registration. 


The base IKEv2 specification includes support for RSA and DSA 
signatures, but the Signature Authentication in IKEv2 [RFC7427] 
extended IKEv2 so that signature methods over any key type can be 
used. Implementations using raw public keys SHOULD use the Digital 
Signature method described in RFC 7427. 


When using raw public keys, the authenticated identity is not usually 
the identity from the ID payload, but instead the public key itself 
is used as the identity for the other end. This means that ID 
payload contents might not be useful for authentication purposes. It 
might still be used for policy decisions, for example to simplify the 
policy lookup. Alternatively, the ID_NULL type [RFC7619] can be used 
to indicate that the ID payload is not relevant to this 
authentication. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Certificate Encoding Payload 


Section 3.6 of RFC 7296 defines the Certificate payload format as 
shown in Figure 1. 


1 2 3 

OD BeBe AO 6: 8895 OT 2) Bh AO 6. EO Os O12 BP An 62 af e O 1 
—t-+-t-4+-4+-4t-4+-4-4t-4+-4+-4-4-t-4-4-t-4-t-t-4+-t-t-4-t-t-t-ta4-4t-t-4+ 
Next Payload |c] RESERVED | Payload Length 
—t-+-t-4+-4+-4+-4+-4+-4+-4+-4+-4-4+-4t-4-4-t-4+-t-t-4-t-t-4-t-t-t-ta4-t-t-4+ 
Cert Encoding | | 
-+-+-+-+-+-+-+-+ | 

Certificate Data 7 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


: +— +— + 


+ — 


Figure 1: Certificate Payload Format 
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To support raw public keys, the field values are as follows: 


o Certificate Encoding (1 octet) - This field indicates the type of 
certificate or certificate-related information contained in the 
Certificate Data field. 


Certificate Encoding Value 
Raw Public Key 15 
o Certificate Data (variable length) - Actual encoding of the 


certificate data. 


In order to provide a simple and standard way to indicate the key 
type when the encoding type is "Raw Public Key", the 
SubjectPublicKeyInfo structure of the PKIX certificate is used. This 
is a very simple encoding, as most of the ASN.1 part can be included 
literally and recognized by block comparison. See Appendix A of 
[RFC7250] for a detailed breakdown. In addition, Appendix A of this 
document has several examples. 


In addition to the Certificate payload, the Cert Encoding for Raw 
Public Key can be used in the Certificate Request payload. In that 
case, the Certification Authority field MUST be empty if the "Raw 
Public Key" certificate encoding is used. 


For RSA keys, the implementations MUST follow the public-key 
processing rules of Section 1.2 of the Additional Algorithms and 
Identifiers for RSA Cryptography for PKIX ([RFC4055]) even when the 
SubjectPublicKeyInfo is not part of a certificate but is instead sent 
as a Certificate Data field. This means that RSASSA-PSS and 
RSASSA-PSS-params inside the SubjectPublicKeyInfo structure MUST be 
sent when applicable. 


4. Security Considerations 


An IKEv2 deployment using raw public keys needs to utilize an out-of- 
band public-key validation procedure to be confident in the 
authenticity of the keys being used. One way to achieve this goal is 
to use a configuration mechanism for provisioning raw public keys 
into the IKEv2 software. "Smart object" deployments are likely to 
use such preconfigured public keys. 


Another approach is to rely on secure DNS to associate public keys 
with domain names using the IPSECKEY DNS RRtype [RFC4025]. More 
information can be found in DNS-Based Authentication of Named 
Entities (DANE) [RFC6394]. 
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This document does not change the security assumptions made by the 
IKEv2 specification since "Raw RSA Key" support was already available 
in IKEv2 in [RFC5996]. This document only generalizes raw public-key 
support. 


5. IANA Considerations 


This document allocates a new value from the IKEv2 Certificate 
Encodings registry: 


15 Raw Public Key 
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Appendix A. Examples 


This appendix provides examples of the actual payloads sent on the 
wire. 


A.1. ECDSA Example 


This first example uses the 256-bit ECDSA private/public key pair 
defined in Section 8.1 of the IKEv2 ECDSA document [RFC4754]. 


The public key is as follows: 

o Algorithm: id-ecPublickey (1.2.840.10045.2.1) 
o Fixed curve: secp256r1l (1.2.840.10045.3.1.7) 
o Public key x coordinate: 


cb28e099 9b9c7715 fd0a80d8 e47a7707 
9716cbhbf 917dd72e 97566eal c066957c 


o Public key y coordinate: 


2b57c023 5fb74897 68d058ff 4911c20f 
dbe71e36 99d91339 afbb903e e17255dc 


The SubjectPublicKeyInfo ASN.1 object is as follows: 


0000 : SEQUENCE 

0002 : SEQUENCE 

0004 : OBJECT IDENTIFIER id-ecPublickey (1.2.840.10045.2.1) 
000d : OBJECT IDENTIFIER secp256rl (1.2.840.10045.3.1.7) 
0017 : BIT STRING (66 bytes) 


00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 
00000010: 7707 9716 cbbf 917d d72e 9756 beal c066 
00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 
00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 
00000040: 55dc 


The first byte (00) of the bit string indicates that there is no 
"number of unused bits", and the second byte (04) indicates 
uncompressed form ([RFC5480]). Those two octets are followed by the 
values of X and Y. 
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The final encoded SubjectPublicKeyInfo object is as follows: 


00000000: 
00000010: 
00000020: 
00000030: 
00000040: 
00000050: 


This will 


00000000: 
00000010: 
00000020: 
00000030: 
00000040: 
00000050: 


Where NN 


3059 
8648 
9c77 
7dd7 
b748 
d913 


3013 
ce3d 
15fd 
2e97 
9768 
39af 


result in 


NNOO 
0201 
cb28 
9716 
2b57 
dbe7 


0060 
0608 
e099 
cbbf 
c023 
1e36 


0607 2a86 
0301 0703 
0a80 d8e4 
566e alcO 
d058 ff49 
bb90 3eel 


the final 


Of30 5930 
2a86 48ce 
9b9c 7715 
917d d72e 
5fb7 4897 
99d9 1339 


48ce 3d02 
4200 04cb 
7a77 0797 
6695 7c2b 
11c2 Ofdb 
7255 dc 


0106 
28e0 
16cb 
57c0 
e7le 


082a 
999b 
bf91 
235f 
3699 


IKEv2 Certificate Payload: 


1306 072a 
3d03 0107 
fd0a 80d8 
9756 6eal 
68d0 58ff 
afbb 903e 


is the next payload type (i.e. 
immediately follows this Certificate payload). 


A.2. RSA Example 


8648 
0342 
e47a 
c066 
4911 
e172 


y the 


ce3d 
0004 
7707 
957c 
c20f 
55dc 


type of payload that 


This second example uses a random 1024-bit RSA key. 


The public key is as follows: 


o Algorithm: 


o Modulus n 


rsaEncryption 


(1024 bits, 


decimal): 


1323562071162740912417075551025599045700 
3972512968992059076067098474693867078469 
7654066339302927451756327389839253751712 
9485277759962777278073526290329821841100 
9721044682579432931952695408402169276996 
5181887843758615443536914372816830537901 
8976615344413864477626646564638249672329 
04996914356093900776754835411 


o Modulus n 


bc7b43 


£5806c2a 


31cadc 


39ae49ed 


fbleb8 
66£368 


47 49c7b386 
ed6a6172 
97 12e209b1 
6ebc30f8 
7b 16ffc5ab 
35 8ceaefd3 
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(1024 bits, 


O0bfa84b 
f£0dc3d4 
fddba58a 
d9b52e23 
Of8f8fe9 


hexadecimal): 


44f88187 
cd601638 
8c62b369 
385a4019 
£7cb3e66 


(1.2.840.113549.1.1.1) 


9a2dda08 d1f0145a 
e8ca348e bdca5742 
O38a3dle aa727c1f 
15858c59 be72£343 
3d8fe9f9 ecfal230 
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o Exponent e 


o Exponent e 


The SubjectPublicKeyInfo ASN.1 object is as follows: 


0000 

0003 

0005 

0016 

0018 : 
00000000: 
00000010: 
00000020: 
00000030: 
00000040: 
00000050: 
00000060: 
00000070: 
00000080: 


The first 


(17 bits, 


(17 bits, 


SEQUENCE 
SEQUENCE 


OBJECT IDENTIFIER rsaEncryption 


decimal): 


hexadecimal): 


65537 


NULL 


BIT STRING 


0030 
00bf 
£580 
e8ca 
fddb 
39ae 
1585 
Of8t 
66f3 


byte 


8189 
a84b 
6c2a 
348e 
a58a 
49ed 
8c59 
8fe9 
6835 


(00) 


0281 
44f8 
ed6a 
bdca 
8c62 
6ebc 
be72 
f7cb 
8cea 


(141 
8100 
8187 
6172 
5742 
b369 
30f8 
£343 
3e66 
efd3 


bytes) 


bc7b 
9a2da 
ffod 
31ca 
038a 
d9b5 
fble 
3d8f 
0203 


4347 
da08 
c3d4 
dc97 
3dle 
2e23 
b87b 
e9f9 
0100 


10001 


49c7 
dl1fo 
cd60 
12e2 
aa72 
385a 
16ff 
ecfa 
01 


b386 
145a 
1638 
09b1 
7c1f 
4019 
c5ab 
1230 
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(1.2.840.113549.1.1.1) 


of the bit string indicates that there is no 


"number of unused bits". 
sequence having 2 integers. 
is the beginning of the sequence, 
the length does not fit in 7 bits, 


length is in the next byte 


tag (02) 


(prefixed with 0 so it will not be a negative number). 
there follows the tag 


modulus, 


and length 


(81 


Inside that bit string, 


81). 


(89). 


The second byte 


(30) 


there is an ASN.1 

indicates that this 
and the next byte 
but requires one byte, 
Then starts the first integer with 


indicates 
so the 


After that we have the modulus 


(02 


) and length 


and the last 3 bytes are the exponent. 


The final 


00000000: 
00000010: 
00000020: 
00000030: 
00000040: 
00000050: 
00000060: 
00000070: 
00000080: 
00000090: 
000000a0: 
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(03) 


After the 
of the exponent, 


encoded SubjectPublicKeyInfo object is as follows: 


3081 
0500 
4749 
08d1 
d4cd 
9712 
leaa 
2338 
7b16 
f9ec 
0001 


al. 


9f30 
0381 
c7b3 
£014 
6016 
e209 
727c 
5a40 
EECS 
fal2 


0d06 
8d00 
8600 
5af5 
38e8 
blifd 
1£39 
1915 
ab0f 
3066 


092a 
3081 
bfa8 
806c 
ca34 
dba5 
ae49 
858c 
8f8f 
£368 


8648 
8902 
4b44 
2aed 
8ebd 
8a8c 
ed6e 
59be 
e9f7 
358c 


86f7 
8181 
f881 
6a61 
ca57 
62b3 
bc30 
72£3 
cb3e 
eaef 


0d01 
00bc 
879a 
TZEE 
4231 
6903 
£8d9 
43fb 
663d 
d302 
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0101 
7b43 
2dda 
Odc3 
cadc 
8a3d 
b52e 
leb8 
8fe9 
0301 
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This will result in the final IKEv2 Certificate Payload: 


00000000: NNOO 00a7 Of30 819f 300d 0609 2a86 4886 
00000010: £70d 0101 0105 0003 818d 0030 8189 0281 
00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8 
00000030: 8187 9a2d da08 d1f0 145a £580 6c2a ed6a 
00000040: 6172 ££0d c3d4 cd60 1638 e8ca 348e bdca 
00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62 
00000060: b369 038a 3dle aa72 7c1f 39ae 49ed 6bebc 
00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72 
00000080: £343 fble b87b 16ff c5ab 0f8f 8fe9 f7cb 
00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea 
000000a0: efd3 0203 0100 01 


Where NN is the next payload type (i.e., the type of the payload that 
immediately follows this Certificate payload). 
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